home *** CD-ROM | disk | FTP | other *** search
/ Developer CD Series 1997 January: Mac OS SDK / Dev.CD Jan 97 SDK2.toast / Development Kits (Disc 2) / OpenDoc Development Framework / ODF-Interest Archive / September 96 / Re Thick, Dashed line bug in.8 < prev    next >
Encoding:
Internet Message Format  |  1996-09-19  |  2.9 KB  |  [TEXT/ttxt]

  1. Subject:     Re: Thick, Dashed line bug in ODF?
  2. Sent:        9/16/96 11:45 AM
  3. Received:    9/16/96 11:45 AM
  4. From:        "Jerry Boetje" <Jerry_Boetje@sec.sel.sony.com>
  5. Reply-To:    ODF-Interest@CILabs.ORG
  6. To:          OpenDoc Development Framework Discussion List
  7.  
  8.  
  9. >>Even polygons aren't as bad as you imply. Usually however, it's a
  10. >>better tack to draw a single pixel broken line n times with
  11. >>appropriate offset. Same trick can be used for caps at the end. X
  12. >>Windows does this pretty well.
  13. >
  14. >This sounds like it would be pretty resolution-dependent to get good
  15. results...
  16. >
  17. It's more aspect-ratio dependent than pixel size dependent. One of the
  18. nice things is that it's possible to precalculate the line drawing
  19. parameters for various dash shapes. This can be extended to different
  20. aspect ratios since there aren't that many different ones in the
  21. world. After that, the imaging runs pretty fast.
  22.  
  23. >>Wouldn't it be nice to have a portable,
  24. >>thick dashed line library that does the right thing?
  25. >
  26. >Yes, it would, and one could probably be written on top of the ODF
  27. imaging
  28. >system, but I don't think it should be part of ODF proper.
  29. >
  30. >_troy
  31. >
  32. but if it's not part of ODF proper, it becomes none portable, leaving
  33. it out in the cold. And the temperature of the non-portable outside is
  34. very low. Obviously this won't be part of a release anytime soon and
  35. it's not killer to leave it out, but it would be good to get it on
  36. someone's request list.
  37.  
  38.   Jerry
  39.  
  40.  
  41.  
  42.  
  43. ---------------------------------------------------
  44. This message was created and sent using the Cyberdog Mail System
  45. ---------------------------------------------------
  46.  
  47.  
  48.  
  49. >>Even polygons aren't as bad as you imply. Usually however, it's a
  50. >>better tack to draw a single pixel broken line n times with
  51. >>appropriate offset. Same trick can be used for caps at the end. X
  52. >>Windows does this pretty well.
  53. >
  54. >This sounds like it would be pretty resolution-dependent to get good results...
  55. >
  56. It's more aspect-ratio dependent than pixel size dependent. One of the nice things is that it's possible to precalculate the line drawing parameters for various dash shapes. This can be extended to different aspect ratios since there aren't that many different ones in the world. After that, the imaging runs pretty fast.
  57.  
  58. >>Wouldn't it be nice to have a portable,
  59. >>thick dashed line library that does the right thing?
  60. >
  61. >Yes, it would, and one could probably be written on top of the ODF imaging
  62. >system, but I don't think it should be part of ODF proper.
  63. >
  64. >_troy
  65. >
  66. but if it's not part of ODF proper, it becomes none portable, leaving it out in the cold. And the temperature of the non-portable outside is very low. Obviously this won't be part of a release anytime soon and it's not killer to leave it out, but it would be good to get it on someone's request list.
  67.  
  68.   Jerry
  69.  
  70.  
  71.  
  72.  
  73. ---------------------------------------------------
  74. This message was created and sent using the Cyberdog Mail System
  75. ---------------------------------------------------
  76.